CD Ware Multimedia 1995 May/cd Ware (Juegos) Epimundo.iso/DOS/TOOLS/GAME_PGM.ZIP/GAMES.ASC

Text File | 1989-02-25 | 42.1 KB | 759 lines

                   THOUGHTS ON THE PROGRAMMING OF GAMES

                                 An essay
                                    by

                              Robert Gellman
                          431 Fifth Street, S.E.
                          Washington, D.C. 20003

                     (C) Copyright 1989 Robert Gellman


          Individuals are granted a license to copy this document
          provided that no fee is charged.  No other use may be
          made without the express written consent of the author.


                                   *****


     FORWARD - by Nelson Ford, Public (Software) Library:  Robert Gellman
is an outstanding games programmer.  We have been happy to have been
associated with him and have many of his games in the PSL. They are all
top-notch.  This document is sort of a "Programmer's Guide" for games
programmers and will be added to disk 1-PG-233, the actual Programmer's Guide
disk from the PSL (1-800-2424-PSL).  If you are interested in marketing your
programs, be sure to read the Programmer's Guide.

                                   *****


     INTRODUCTION - I have been a user and programmer of shareware and
freeware computer games for several years.  As a programmer, I know how
exacting it can be to design a workable, fun game.  Those who do not write
programs take features like clear screens, high score tables, and game flow
for granted.  They do not understand the exacting (and often unexciting)
decision making involved in designing the games, the screens, the order of
keystrokes, etc.

     Unfortunately, it seems that some programmers don't understand these
points either.  I have found it necessary to discard many interesting games
because of defects, lapses, and mistakes.  Some programmers get so tied up
in their own programming that they do not consider how users will react to
the game.  I have been guilty of this myself at times.

     What makes a game interesting or addictive?  What features are so
annoying that they inhibit registration?  This memo is my attempt to share
my own views -- my own prejudices -- on game play and programming.  If it
helps you, fine.  If you disagree, thanks for listening.  If you want to
pick a fight, please write to me.



     GENERAL ADVICE - Let everybody play your game in his or her own way.
Don't insist on imposing your perspective on users.  Don't assume that
everyone will share your own narrow views of what is fun about the game.
People will see things in your program that you didn't.  You can push
people gently in the direction you want them to go, but don't be
inflexible.

          Example:  I was working on a program involving the guessing of
     words.  I found that one of my program testers guessed collections of
     letters rather than real words.  I protested that he was "cheating".
     He told me to mind my own business.  He liked playing the game HIS
     way, and he didn't care what I intended.  I compromised by adding an
     artificial scoring system that rewarded those who played the game the
     way I intended.  Anyone who disagreed could easily ignore the score
     and have fun their way.

          Example:  One of my solitaire games often reached a point where
     more cards could be moved even though it was clear that victory was
     impossible.  Some people quit the instant that failure was certain,
     and I didn't like that.  My response was an artificial score that
     rewarded both winning AND lesser progress.  This gave players an
     incentive to keep playing short of victory.  Those who only care about
     winning are free to ignore the score.

     Something that is important to you may not be important to the next
player.  A minor feature of a program may offend a potential registrant.

          Example:  The author of a solitaire game was obsessed by the
     game's statistics.  In order to preserve statistical "purity", the
     author would not let you end a game in the middle.  You could save a
     game in the middle, but the program created a read-only file to hold
     the saved game.  This was done so you couldn't easily erase it.  I
     liked the game a lot, but I didn't care about the statistics.  I was
     so outraged by the creation of a read-only file for such a silly
     purpose that I discarded the game rather than registering it.

     Many programmers regularly enhance their programs with new features.
This can be a good thing.  The problem is that new features do not always
improve a program.  Some changes just add unwanted choices and
complexities, and waste bytes.  Features that are fun to program are not
always fun to play.

     I have seen some practical programs and fun games grow so large and
complex that I stopped using them.  A gigantic, lumbering program may lose
its disk space to a small, tightly written one.

          Example:  I have several versions of GO-type games.  Two are
     almost identical.  The first has on-line instructions and fancy
     screens.  The second is not as fancy, but it is just as much fun.
     The program is very small.  I now use the second program and save
     25,000 bytes.


     If you are writing a commercial game with a high price tag, the fancy
screens and the bells and whistles might be necessary to impress potential
buyers.  These glitzy features help sell games in stores.  Shareware
doesn't work that way.  A user gets to play with the game over an extended
period.  The user learns if the game is fun or cumbersome before paying for
it.  Do you own any fancy games that sit unused because they didn't turn
out to be as much fun as they looked?  How many public domain versions of
commercial games do you use despite the absence of showy graphics?

          Example:  There is a game called Tetris (commercial) or Nyet
     (public domain).  It is a simple game, fun to play, and extremely
     addicting.  The commercial version has extraordinary graphics.  The
     public domain version is sparse.  The play is virtually the same for
     both games.  Once you get the hang of the game, you don't care about
     the irrelevant graphics.  They add nothing to playing the game.

     WHAT GAME TO PROGRAM? - Some programmers write excellent programs, but
they pick the wrong games to program.  Some games just don't lend
themselves to play on a computer.  Single player games require careful
selection.

          Example:  The standard solitaire game (usually called Klondike)
     is not especially suited for a computer.  It requires little thought
     and a lot of card movement.  There is no convenient way to designate
     movements.  People have tried pile numbers, card identifiers, and
     cursor keys.  All require a lot of keystrokes, and the keystrokes bog
     down the game.  It is usually simpler to play the game with a real
     deck of cards!

          Example:  Another solitaire game called La Belle Lucie requires
     that the entire deck be dealt in fans of three cards.  Cards are
     moved, and the deck is reshuffled and redealt several times.  The
     computer is wonderful at shuffling and dealing repeatedly.  The player
     still has to enter moves, and the designations require several
     keystrokes.  Since the game requires a lot more thought than Klondike,
     the keystrokes are not as noticeable.  The player is busy doing
     something other than mindlessly hitting keys.

          Example:  Yet another solitaire game that is well suited to a
     computer is Poker Solitaire.  The game calls for the player to place
     25 cards in a five by five grid in order to make poker hands across
     and down the grid.  Each hand is then evaluated and scored according
     to a table of values.  It is a great game, but to play it by hand, you
     have to add up the scores.  The computer handles the math in an
     instant.

     I recognize that people have different tastes, and some will like
games that I don't.  It is not my purpose to demean those who like Klondike
solitaire.  My point is simply that some games are better suited to play on
computers than others.  Repetitive tasks, comparisons, and calculations are
easily done by computers.  Games are only worth computerizing when the
advantages of computers outweigh the difficulty of issuing instructions.

     I have another point to make using Klondike solitaire as an example.
There are many shareware or freeware versions of this game.  Unless you can
do it better, why not pick another game to program?  The world just doesn't
need another version of Klondike.  There are many other card games for
which no computerized version exists.  Be the first one on your block . . .

     INSTRUCTIONS - There are two basic ways of providing game
instructions, each with advantages and disadvantages.  The first way is to
have all instructions on-line.  Instructions may be offered at the
beginning of the game, during play, or both.  The main advantage is that
the instructions are always available.  If you have the game file, you
probably have the instructions as well.

    The drawback is that when instructions are part of the basic game file
(or in a separate but required file), the game uses more disk space.  All
other things being equal, the best games are small and fit in one file.
This is not always possible, but it is a worthy goal nevertheless.

          Example:  A game I just reviewed has a 45000 byte instruction
     file separate from the main program file.  The instruction file is not
     a DOS text file and is only readable through the main program.  The
     result is that I must either keep the instructions on my hard disk and
     waste a lot of disk space or do without them entirely.

     Another problem is that the user may not be allowed to page through
the instructions at his or her own pace.

          Example:  One game begins by asking the player if he wants
     instructions.  If you say "yes", about 15 screens worth of
     instructions follow.  The screens are timed and change on their own
     accord rather than at the user's pace.  As a result, slow readers may
     miss key instructions and fast readers are bored silly.  To make
     matters worse, if you want to reread one page, you must go through the
     entire set of instructions to find that page.  This wastes my time,
     and I may miss the key page anyway while I am bored and waiting.

     Another consequence of on-line instructions is that it may be
impossible for the user to print them out.

          Example:  One game presents instructions on the screen in
     graphics mode.  They look great, but you can't even use PrintScreen to
     provide a written copy.  The same instructions could have been
     presented in text mode in a file that would be 75% smaller.

     Not all games lend themselves to having on-line or pop-up
instructions.  Nevertheless, pop-up instructions are a very good choice if
they are short.  No more than two screens of instructions should be
provided, and one screen is best.  When games have on-line instructions
that go on for page after page, I always feel that I am wasting disk space
once I have learned the game.  Instructions are important, but they are
needed for only a short period.


     Pop-up instructions are always available to players and won't become
separated from the game file.  Players can call up the instructions
whenever needed (even if access must be limited during certain parts of the
game).  If the instructions do not exceed two screens, the game file will
only be marginally larger.

          Example:  By using a library of QuickBASIC programming tools, I
     am able to include pop-up screens in my games without the need to use
     graphics mode.  The tools allows me to create virtual screens.  The
     result is that my games can be played on computers without graphics
     cards.  File size is only a few thousand bytes larger, and my game
     still requires only one file.

     The second way of including instructions is to have a separate
document file.  For example, GAME.EXE may be accompanied by a GAME.DOC
file.  This is a reasonable approach, especially for longer files.  A
document file should always be an ASCII file that can be read by programs
such as LIST, BROWSE, or even by the DOS TYPE command.  Long files intended
for printing should have page breaks.

     To help those who use word processors to edit extraneous material from
document files before printing, the document file should list appropriate
margin settings at the beginning of the file.  Guessing at the author's
margins is frustrating.  Remember that some popular laser printers cannot
print on the first and last two columns of the page.  Documents with
margins at 0 and 80 cannot easily be printed on these printers.  This
document was created with margins of 5 and 75.

     There are programs that enable programmers to turn DOC files into COM
files that are executed rather than read.  GAME.DOC becomes GAME.COM.  Upon
execution, the text appears on the screen and can be scrolled through using
cursor keys.  This is a cute but less attractive alternative.  The files
cannot be easily reviewed or printed, and the resulting COM file will be
larger than the plain DOC file.

     Perhaps the best choice is to have on-line help AND a separate, longer
document file.  This is the best of both worlds.  The separate file can be
discarded once the player learns the game sufficiently so that the on-line
help is adequate.  A programmer who knows that the separate file is to be
read and discarded can expound at greater length about the program without
impinging permanently on someone else's disk space.

          Example:  I usually include a comment early on in a documentation
     file stating that the file is intended for printing.  I suggest that
     the user read it once or twice and then forget about it.  This way I
     don't feel guilty about including a history of my program that
     interests no one but me.

     Yet another approach is to make the rules available but not mandatory.
I like to program my games so that the initial screen allows a choice.
Players can skip the rules by hitting the space bar or review the rules by
hitting ENTER.  The space bar is a great switch because it is so easy to
hit.  This is simpler than making the player answer the "Instructions
(Y/N)?" question each time.
     FILE NAMES - If a program requires more than one file or creates extra
files on its own, all files should have a common name.  For example, if
GAMES.EXE has other files, the first part of the name should be GAMES.
Other files might be GAMES.DOC, GAMES.PIC, GAMES.HLP, GAMES.TXT, and
GAMES.SCR.  This keeps all files together in a standard sorted directory
listing.  The user knows immediately by the name which files go together.
This helps immensely when one person passes the game on to another.

     FILE CREATION - Some games require only one file; some games need 50
files.  One file is best, but not always possible.  Some games create files
along the way to save high scores, setup information, and other records.
Keep the number of these files to a minimum.  Don't litter your user's disk
with endless tiny files.

          Example:  One excellent poker game created several tiny files to
     hold high scores, setup information, statistical data, and a history
     of play.  The history file was only a few bytes long, and the other
     files were small as well.  The files could have been combined in a
     single file.  As an alternative, the author did allow a player to turn
     off some of the files.  That was good, but in order to turn off the
     record keeping, a permanent, tiny setup file had to be written to disk
     with the instructions.  Win some, lose some.  A default for "no files"
     would have been welcome.

     HIGH SCORE TABLES - Some games allow players to save a record of their
best efforts in high score tables.  The availability of a high score table
can be a CRUCIAL element in the success of a game.  It offers a player an
immediate and obtainable goal:  put a score in the high score table.  The
ability to record high scores and to improve upon them over time can make a
game addicting.  Games that lend themselves to keeping scores should
include a high score table.  I have discarded perfectly good games because
the absence of a high score table diminished my interest in the game.

          Example:  I got a public domain arcade game from a friend, along
     with his high score table.  He was an experienced player, and his
     scores were high.  I played the game for a while, but I didn't even
     come close to making the high score table.  I decided the game was not
     too interesting.  When I learned how to blank out the table, I started
     playing again and did nothing else for three weeks straight.  The
     ability to see success in the high score table transformed the game
     into an addicting challenge.  I beat my friend's scores in three days.

     There are several aspects of high score tables to be discussed.
First, how many scores should be maintained?  One game I played saves 40
scores.  The problem is that you have to play the game 40 times before you
run the risk of not having a score in the table.  That is too easy.

     Another game saves only one score.  That is frustrating in its own
way.  A stupendous but second-best effort warrants no recognition.  It
becomes so hard to beat a once-in-a-lifetime score that a player may stop
playing.  This will happen eventually, but if there are more scores, the
frustration of failure is postponed longer.

     I think that 10 scores is a good choice, but not the only choice.
Some games offer two high score tables:  a daily table and a permanent
table.  This allows two different opportunities for success.  The daily
table disappears when the user quits the program; good scores live on to be
beaten another day.

     Another important point is providing the ability to wipe out the
scores in the table to accommodate a new player or just to start again.
Some games offer switches to wipe out the scores.  This is fine as long as
an accidental erasure is not likely.  A player can develop a real sense of
"investment" in a high score table, and doesn't want the scores to
disappear easily.

     Some games tolerate the erasure of the file itself.  If no high score
file is found on the disk, the necessary file is created.  This is a
reasonable approach.  But some games will not work if the high score file
is missing.  They can write to -- but not create -- the necessary file.  In
these cases, it may take a byte editor to remove old, unwanted high scores.
This should be avoided since not all users are so sophisticated.

     Another nice touch is placing a single score in an otherwise empty
table as a target for new players.  Don't fill up the table so that new,
low scores will be crowded out.  A medium score (for a good player) at the
top of the table will seem almost unattainable to a new player.  When that
score is surpassed, there is a real sense of accomplishment.  The next
goal, of course, is to have all scores higher than the original target.

     Some players may not want to litter their disks with a permanent table
or may want to "protect" the table from others.  Consider asking whether
the player wants to record high scores in a table.  The question can be
asked once per session, preferably at the conclusion of the first game.

     Since a file uses a minimum of 1000 bytes on a floppy and 2000 bytes
on a hard disk, a table has plenty of room for information before it grows
beyond minimum size.  I mentioned above a game that has 40 scores in its
table and another that has only one.  Both use the same 2000 bytes on my
hard disk.  I prefer tables that automatically include the date each game
was played.  This helps to track "progress" and feeds the addiction that a
good game engenders.  The date can be added to most tables at no increase
in file size.

     One small note to remember is that many high score tables are used
exclusively by the same player.  The same name or initials appear on each
of the scores, and the same date may also appear.  Make sure that a new
entry in the list is highlighted so that it can be spotted easily.  After I
enter my initials and the score is placed in its rightful spot in the list,
I may forget exactly which score I just achieved.

     The name for the high score file should be the same as the name of the
program file with a separate extension.  This permits instant
identification of the table with the game in the event that the files are
moved or erased.

          Example:  I have several files in my arcade directory with names
     like HISCORE, WINNERS, GATEWAY.BBS, etc.  I do not know which file
     belongs to which program.  Some may belong to games long since
     discarded, but I can't be sure.  If the file contents are not in ASCII
     text -- scores are usually integers and not stored in ASCII -- I can't
     even TYPE or LIST the file to read the numbers.  Of course, I can't
     change the file names because a program won't find the table under an
     assumed name.

     Finally, some tables allow space for a winner to enter a 15 or 20
character name.  Some just allow three initials.  Either is acceptable.
Make sure that you allow the user to backspace over a mistake.  Some
programs record the ASCII symbol for CHR$(8) when you hit a backspace, and
there is no way to get rid of it.  Allow all letters, characters, and
symbols to be entered.  Don't assume that everyone will want to use the
field you have provided in the way that you intended.  I like to put in the
date, but some programs won't accept numbers or slashes.

     Also, I don't like programs that ask players their name at the
beginning.  It gives a program a very old fashioned look.  A program that
asks "What's your name?" harkens back to the old days -- say 1984 or so.

     SOUNDS - Games are often embellished with sounds that reflect the
action.  With few exceptions, the sounds grow very annoying very rapidly.
This is especially true for music.  The constant repetition can drive you
crazy -- and anyone else in the same room or house.  I only know of one
game whose sounds I don't suppress.  (It's Willy the Worm I, if you must
know.  The sounds are cute, related to the action, and very low-keyed.)

     Include a sound switch.  There are two types to consider.  First is a
switch set when the program starts that will eliminate all sounds during
the current session.  A player who wants to play at 4 a.m. should be able
to start and run the game in silence.  The default should be for no sound.

     This will annoy programmers who put in sounds to dress up their
programs.  Everyone thinks his sounds are great and wants to make sure that
others hear them.  Yet I am willing to bet that most programmers find the
noise sufficiently annoying that they kill the sounds during program
testing.  Give your user the same option.  I have discarded many programs
simply because there was no way to silence them.  It is a shame to drop a
perfectly good program (and see a programmer lose a customer) over such a
small point.

     A second type of sound switch toggles sound on and off in the middle
of the game.  This is good, but can be more complex to program.  Do it if
possible.  It lets the user listen once or twice and then stop the music.

     Many programs need sounds to signal mistakes.  Sounds can be better
than screen messages for this purpose.  Some programmers use the standard
DOS BEEP.  This is a long, loud, and obnoxious sound, and I hate it.  I
have discarded an occasional program rather than face an evening of BEEPs.
I just found -- and immediately erased -- a game that signaled a mistake
with three consecutive BEEPs.  I didn't even finish one test game.

     If you need a sound, find an alternative to BEEP.  In BASIC, I have
found that the command SOUND 5000,.5 produces a short, low level sound.  It
gets your attention, but it won't wake up the neighbors.  Shorter sounds
may work as well.  You can get a barely noticeable click with SOUND,
10000,.04.  Play (pun intended, for BASIC programmers at least) around with
sounds.  Take note (this is contagious!) when programming.

     WHERE ARE YOU? - A programmer should include his or her name and
address on one of the game screens.  Shareware authors do this, of course,
but freeware authors should do it as well.  I occasionally want to contact
authors to point out a problem or make a suggestion, but some programmers
don't tell me where to write.  Don't expect everyone to have access to
Compuserve.

     The address can be an optional screen somewhere, but don't expect
everyone to wade through the documentation to find your address.  If you
want to hear from users, make it easy for them.  How else are you going to
get error reports?  You didn't really think your program was bug free, did
you?

     KEYSTROKES - One of the most important rules for game programming is
that keystrokes should be minimized.  Unnecessary keystrokes can undermine
the best game.  Don't ask the player to hit keys to tell the computer
something that the computer can figure out on its own.

          Example:  I found a solitaire card game only permits building
     card by suits.  The 8 of spades can only go on the 9 of spades.
     Nevertheless, to move that 8 to the 9, you had to enter:  8S9S.
     Because of the way the game worked, it was unnecessary to specify the
     9S.  Either the card goes to the 9S or the move is improper.  Since
     the programmer released the source code for the program, I was able to
     rewrite it to eliminate the unnecessary keystrokes.  It speeded up
     play enormously.

          Example:  Another program requires action by the player followed
     by messages from the computer.  To clear each message, the player has
     to hit a key.  This brings up the next message.  Hit another key and a
     third message appears.  All three messages are short and would fit on
     one screen.  The same circumstances happen over and over again during
     the game, and the repeated keystrokes soon grow to be wearisome.

     One keystroke often not considered by programmers is the ENTER key.
When a player is offered a choice of Yes or No, there is usually no reason
to have to hit the Y or N plus the ENTER key.  Hitting Y alone is enough.
This also works for menus.  This saves a lot of extra work for players and
speeds up play.

          Example:  One text editor I tested asked for confirmation before
     executing a destructive command.  That is perfectly acceptable.
     However, the program demanded that the user hit Y and then ENTER.
     This grew very tiresome very fast, and I dropped the program
     altogether.  I probably would have registered it otherwise.  Major
     decisions (like registration) can turn on very small points.

     However, sometimes the ENTER key is necessary on its own because the
input length is variable.  Sometimes the ENTER key serves another purpose.
It becomes a confirmation key, a final opportunity for the player to review
the input (assuming it is visible on the screen) and make a change.  This
use of ENTER is acceptable if it is important or necessary.

     Some programmers actually forget that many players use a keyboard.
Anyone who routinely uses a mouse may overlook keyboard problems.

          Example:  A wonderful game that required players to designate
     coordinates on the screen identified both X and Y coordinates with a
     letter/number combination.  Thus, a particular spot on the board was
     entered as A1,Z1.  This took a lot of keystrokes.  I suggested to the
     author that the program be redone so that the X coordinates could be
     marked with a letter and the Y coordinates with a number.  This cut
     the number of keystrokes by half.  The author liked the suggestion and
     adopted it.  He explained that he and his friends all used mice and
     didn't think about keyboard play!

     Another aspect of defining user input is the combination of keys
required and the fingers required to enter the combinations.  It is basic
but worth mentioning that logical and convenient combinations be used.
Don't ask your user to reach all over the keyboard when playing an intense
arcade game.  People only have two hands!  If you need to keep your right
hand on the cursor keys and your left hand on A-W-S-Z, it is very hard to
hit number keys.  Don't ask your users to do the impossible.

     Remember as well that there are many different types of keyboards.  If
you are programming an action game, consider whether it is a good idea to
ask a player to hit the F10 key.  For some, this key is easy to find with
the left hand.  With newer keyboards, it is hard to hit F10 with the left
hand.  I recommend that the function keys be avoided if possible unless the
key can be struck at leisure rather than during an attack by aliens.

     One of the best all-purpose keystrokes is the space bar.  It is the
biggest key on the board and the easiest to hit.  I use it as much as
possible.  For example, I often ask the player to hit ENTER or space bar to
continue.

     Finally, try to make the keystrokes consistent and easy to remember.
If possible, use one general key for the same purpose throughout.  Use the
escape key, for example, as a general cancellation key.  Use the space bar
as a general acceptance key.  Just don't have the same key do different
things at different times.  It is too confusing.

     SPEED - Speed kills many arcade programs.  A game that is just perfect
on a PC may not be playable on an AT.  Computers operate at so many
different speeds now that new arcade game authors must take speed into
account.  Learn how to adjust the speed of your game automatically.  No one
will register a game that is too fast or too slow for his machine.  I
occasionally run a slowdown program so that I can play an especially
intriguing game.  Still, I am not likely to register a game when I have do
some of the work.  More often, I have discarded games with great regret
because of speed problems.
     COLOR AND GRAPHICS - Some games require either color or graphics or
both.  Color or graphics can be an essential element of the game.  If that
is the case, then so be it.  But many games demand color or graphics when
they could run just as well in text mode on a monochrome monitor.

     I don't understand why some shareware authors unnecessarily limit the
market for their products by using color when it is not necessary.  For
some games, clever programming can provide graphics-type effects in text
mode.

          Example:  I program games that use playing cards.  I have learned
     how to draw cards using text boxes.  The result is that the program
     looks good and will run on any type of monitor.  The use of graphics
     would produce a better looking card, but the game would still be the
     same.  And the play is the thing that sells programs.  Glitz and color
     won't save a bad game.

     The best of both worlds is to be ambidextrous.  Provide color for
those with color monitors and allow black and white for those without.
This flexibility can be provided very easily, and without significantly
increasing the size of your program.  It is also easy to find code that
will enable the program to tell what kind of monitor is being used.  There
is no reason to ask the user if the monitor supports color.

     A recent trend is the programming of games that require an EGA (or a
mouse).  The same considerations apply here as well.  Don't limit your
market unless it is necessary (and it is much of the time).

          Example:  I recently saw a game that required both an EGA and a
     mouse.  How many computers have both?

     Having made this point, I feel obliged to recognize that some games
are created by programmers for their own systems.  Sharing them with the
world is a secondary consideration.  Other games really require an EGA and
a mouse.  Just don't complain if you don't get any registrations!

     EXITS - I am not sure that it is still necessary to remind programmers
that they must provide an exit to DOS.  It is absolutely unreasonable to
expect a user to reboot to leave your game.  There are other exit issues
that need to be discussed.

     First, for arcade type games, include a switch that will let the
player pause the action when the phone rings.  Pick something easy to
remember that doesn't require the fingers to move too far from your game's
home keys.  If it's not otherwise in use, the Escape key is a good choice.
Besides being able to resume the game from the paused state, a player
should also be able to exit to DOS as well.

     Games that are not time sensitive (e.g., a solitaire game) do not need
pause switches.  They should still allow players to exit to DOS from any
point in the game.  I hate it when I am faced with the choice of rebooting
or continuing to play a game when I don't want to any more.

     Second, I like games that allow me to restart from the beginning
whenever I want without exiting to DOS.  I may be playing an arcade game
and I know that I need to score 5000 points with my first man in order to
do well.  Yet here I am, two men down with only 1500 points.  I want to
stop this game and go back to the beginning to try again.  Give me that
option.  The need for this option is not limited to arcade games.  If you
want to discourage this conduct, include an exit switch and an average
score feature.

     Third, I want to make the same point another way.  I have found some
games that do not allow you to have a replay without a visit to DOS.

          Example:  I recently found a very creative Breakout-type game.
     There was a multi-step sign-on process (including a sound switch and
     an instruction screen with a welcome bypass) that asked the player to
     select a skill level.  When the game was over, you were dumped back to
     DOS.  To play again, you had to go through the entire sign-on process
     again.  This is a sure cure for addiction.

     I prefer games that include a "Play again" switch at the end, with a
default for another game.  One way to do this is to ask the player to hit
"Q" to quit or to hit any other key to play again.  For the player, this
makes it easy to keep playing.  For the programmer, it helps to foster
addiction by players.  Playing again becomes the path of least resistance
(I know it's 3 a.m., but just ONE more game).  If the game has skill
levels, the player could be asked to hit a different key to change the
default level.  Then it becomes Q to quit, D to change defaults, and any
other key to play again.

     MESSAGES - I have found different opinions about the types of messages
included in games.  Some people like a little personality in the games;
others are offended by a taunt or insult from a program.  I am not sure
that I have any firm advice to offer.  Still, there are some things I like
and some I hate.

          Example:  When a player won a game (an old NIM program), the
     computer stopped before its final losing move and flashed the message
     "You must have cheated".  I found this to be obnoxious, especially in
     a game aimed at kids.  Be a good sport when your program loses!

          Example:  The cutest messages I ever saw were on a GO-type game.
     When the computer won, the message was "Computers are superior".  When
     the player won, the message was "Humans are lucky".  The first message
     conveys the mildest of taunts; the second suggests an all too human
     annoyance at being beaten.  These messages always bring a smile.

          Example:  My own poker program taunts a losing player by
     occasionally asking "Another game, sucker?"  This generated a couple
     of complaints.  I kept the messages (it's my program, after all), but
     I decreased the frequency.  It would probably be better to allow the
     message to appear only once or twice in a session rather than
     repeatedly.  These type of comments wear out their welcome quickly.

     I also like it when I win a game and get a "reward" in the form of a
cute message or colorful display.  A musical serenade is less welcome.  I
find it mildly disappointing to win a hard game after many tries only to
get the same old "Play again?" message.  This is not a big deal, but I like
a little recognition from the programmer that I have mastered the game.

     For a game that produces a score (i.e., play until you die) rather
than a clear victory, scaled messages can be fun.  For new players just
learning how to play, the appearance of a heretofore unseen congratulatory
message is a mark of progress.  One of the best messages I ever saw was the
first in such a series from a great arcade game.  When you got a very low
score, the message was "What's the matter?  Didn't you read the
instructions?"  This was especially telling when, in fact, I had begun
playing without reading the instructions.

     All messages get old pretty quickly.  Even if you include a large
number of different, randomly selected messages, they will all become
routine in short order.  Include them anyway if you like, but don't let
them get in the way.  Don't require an extra keystroke to bring up or
eliminate the message.  Don't let your message become a pain or an
impediment.  Allow it to be ignored.

     COMMAND LINE SWITCHES - Don't use command line switches for anything
important.  No one will remember what your switches mean.  If you have
multiple options, set defaults and offer a menu instead.  A single command
line switch aimed at adapting the program for use by a small class of users
is not unreasonable.

          Example:  One game I liked had half a dozen important command
     line switches.  You even had to use a switch to have the option to
     play more than one game at a time.  I could never remember which
     switch was which, and I tired of it very quickly.

     The use of environmental variables is an alternative to command line
switches.  I hate to use environment space for games that I may play only
from time to time, but I will if I like the game.  I probably won't learn
your command line switches.

     SPELLING - Game displays, instructions, and documents often contain
words that are misspelled.  I estimate that two out of three programmers
don't know the difference between "its" and "it's".  For those of us who do
know the difference, these mistakes are jarring.  One solution is simple.
Run your document files through a spell checker.  Have some one else read
them for sense, spelling, and grammar.

     I asked two people to read this document before I released it.  I also
spell checked it many times, and I even ran it through a grammar checker.
Each review identified some errors.  No one is perfect, and mistakes can
slip by any of us.  But too many programmers give the impression that they
didn't even try.



     PRICE - How many players register shareware games?  I haven't a clue.
The games I have written are all freeware.  I have registered a few games,
but not that many.  After all, you tend to play a game intensively for a
while and then move on to the next one.  Remember Atari video games!
Novelty is very important.  When was the last time you played Pitfall?

     If you are trying to earn money through shareware games, the trick is
to get the user to register during that period of intense play.   One thing
that inhibits registration is price.  Some games are exorbitant.

          Example:  I recently found a good snake game.  There are many of
     this type of game around, but this one was superior.  The author wants
     $25 for it!  There is no way that I would pay that much for a game,
     and I declined to get the enhanced game that came with registration.
     I would have paid five or ten dollars.

     Shareware should be cheaper than commercial software because there are
no fancy packages, retailers or distributors.  The programmer is just as
well off because he keeps all the money.  Games (and other shareware)
should be priced to reflect this.  You can buy some major commercial games
for $25 or less.

     I believe that the price of a shareware game should not exceed $10
unless the game is extraordinary in some way.  It is easier to get someone
to stick a five or ten dollar bill (or check) in an envelope during the
period of intense preoccupation with a game.  A lower price may have other
benefits as well.

          Example:  Last year, I found a stunning game on a bulletin board.
     I registered it immediately for $5.  I even told the author that the
     game was worth twice that.  I was so impressed that I uploaded the
     game on many bulletin boards, with a rave review.  I never would have
     done any of this for a $25 game.  The author reported that the word-
     of-mouth advertising increased registrations considerably.

     I think that much non-game shareware is also too expensive.  I will
pay as much as $25 for a major program (such as a text editor or DOS shell)
that I use regularly.  While I have spent a few hundred dollars on
shareware, I have yet to find a program worth more than $25.  I don't need
or use the semi-commercial shareware like PC-Write that has a very high
price but also has real support.

     I am reluctant, however, to pay much (or at all) for small utilities
that offer minor improvements and that will likely be superseded by better
programs.  I have seen at least ten different WHEREIS programs.  Why should
I pay you $20 because your program is 5 percent faster?  Nevertheless, I
have been known to send $5 for a well done utility that fully meets a need.
That is about the limit for small utility programs.

     A last thought on price:  The amount of work that you put into a
program has nothing to do with its value to me.  Look at the market; look
at the competition.  If there are seven public domain Klondike solitaire
games out there, you will be hard pressed to explain why your version is
worth my money.